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Abstract 



D. I. Parnas has recently proposed [l] a new programming control 
structure - the it-ti . Phis construct is a synthesis of several 
ideas in programming theory including iteration, conditionals , 
and Dijkstra's guards [2]. It has been implemented in a LISP 
interpreter [S] as a more structured replacement for the tradi- 
tional prog construct . Several programming examples are given 
that compare the use of the it-ti wish the more conventional pro- 
gramming constructs. These examples will also show that the it- 
ti fails to satisfy several criteria for programming constructs 
including manageability and visibility. An appendix to this 
report contains an extension of Dijkstra's concept of the ’weak- 
est precondition' to the it-ti. 



1 . Introduction 

D. L. Parnas [l] has recently proposed a new programming control 
structure he calls the it-ti iteration) construct after the 
fashion of do-od, if-fi , and case-esac . It is a synthesis of two 
concepts of structured programming (iteration and conditional 
execution) and is a direct descendant of Dijkstra's do-od and 
if-fi [2]. Reference [l] contains a detailed and mathematical 
treatment of the new construct for both non— deterministic and 
deterministic programming. 

While the it-ti is certainly an interesting proposal and has 
filled a niche in Navlisp, we will see that it fails to satisfy 
several requirements of good programming. 

To motivate the new construct , let us look at one of the 
thorns of structured programming [ 3 ]: the mid-exit loop, illus- 
trated by a sequential array search. The task is to find an ele- 
ment X in an array A. If it is found, function P is passed the 
index of an element of A that contains K. If it is not found, 
function N is called with X as its parameter. A straight- 
forward, non-structured implementation in pidgin— code* of this 
task might be: 



* 3y pidgin-code we mean to indicate a language that 

incorporates features of several languages, and that we are 
free to modify as the need arises. 






loon: 



index := 1 ; 

if index > sizeof 1 A tnen goto r.otfcuni; 
if (A[ index] = X) then goto found; 
index := index + 1 ; 
goto loop; 
notfound: X ( X ) ; 

goto continue; 
found: index 

continue: 

As Xnuth [3] points out, there is really no satisfactory way to 
solve this problem with 'structured ' programming. If we restrict 
ourselves and do not use any goto statements, we might solve the 
problem in one of the following ways: 

Solution J_ 

found := false; 
for i := 1 to sizeof(A) do 
if (A[i] = K) then 
found :- true: 
index := i; 
endif ; 
endfor; 
if (found) 

then F( index); 
else IT(K) ; 
endif; 

Solution 2 

found := false; 
index := 1 ; 

while (not found and index <= sizeof(A)) do 
if (A[ index] = X) then found := true; 
else index := index + 1 ; 
endwhile; 

if (found) then 7 (index); 
else N(K) ; 
endif; 

Solution 3 

index := 1 ; 

while (index <= sizeof(A) cand A[ index] <> K) do 
index := index + 1 ; 
if (index > sizeof(A)) then N(K); 
else ?( index); 

Solution 1 is obviously inefficient. The whole array is searched 
even if K is the first element. This could be an important con- 
sideration if the array A is large. Solution 2 is somewhat 
better, but the truly efficiency-minded point out that found 
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Solution 3 



removes the variaole but depends on conditional evaluation of 
boolean expressions. Shat is, the right-hand expression of a 



-9. an h is evaluated only if the left-hand expression evaluates to 
true. In our example the cand prevents us from exceeding the 
array bounds of A. Zven so. this solution still checks the value 
of index twice: once in the boolean expression of the while . and 
again uoon exit from the while to determine why the loop ter- 
minated . 



Bote that the usual response to these criticisms is "Who 
cares?", and that is the correct response 99 ^ of the time. The 
readability and maintainability of code must take precedence over 
efficiency almost all of the time. However, occasionally, a 
piece of code will occupy a critical position (e.g. in an inner 
loop) and the question becomes important. Again, the usual 
response is "Code it in assembly language". But this implies 
that readability and maintainability must be sacrificed in some 
situations for efficiency. A more desirable goal is a set of 
structured programming disciplines that promote readability and 
maintainability without sacrificing efficiency. 

The Sahn-construct [3.4] attempted to solve this problem 
with an escape mechanism. The following implements the array- 
search with a Zahn construct using the notation of Knuth [ 3 ]). 



index : = 1 ; 

loop ’until found or notfound: 

if (A[ index] = K) then found; 
index := index + 1 ; 
if (index > sizeof(A)) then notfound; 
repeat ; 

then found => F( index); 

notfound => N(K); 
ii; 

Seme find this less satisfying than ormhodox structured program- 
ming or programming with goto statements. Some of the problems 
with the Zahn-construct derive from the structure's lack of visi- 
bility and readability. For example, to trace the results of a 
particular event, (e.g. found) the reader must scan the then 
clause for the event label - the target of the event - much as he 
would have to scan for the target of a goso . While some of these 
problems might be resolved with appropriate syntactic 'sugar', 
the Zahn-construct is still a nox-very-well disguised goto , 
replete with label. This can be appreciated better by drawing the 
control flow graphs for the if-then-else , repeat-until, etc., and 
comparing them ’.nth the control flow graph for the Zahn-construct 
(q.v. section 3. below): the Zahn-construct does not have a sim- 
ple flow graph. About its only advantage is that the Zahn- 
construct forces the programmer so locally declare the labels in 
the context of ’use. 



: ns true 



Farnas has proposed a generalisation of Dijkstra's do— od itera- 
tion) and if-fi (conditional) constructs. The basic syntax of 
the it-ti is given below in a close facsimile of Farnas' nota- 
tion~where <break/repeat> represents one of the keywords break 
or reneat. 



pi -> si <break/repeat> 
p2 -> s2 <break/repeat> 
p3 -> s3 <break/ repeat > 



pn -> sn <break/repeat> 
ti 

The semantics of the it-ti are straightforward. The predicates 
pi are evaluated sequentially -until one evaluates to true. If pi 
is true, then the sequence of statements sj are evaluated. The 
last element of sj is a keyword that specifies whether the it-ti 
is to be executed again (repeat), or exited (break). It is an 
error if none of the predicates pi evaluate to true: in this 
case, the program aborts. 



The following shows how an it-ti could be coded in a conven- 
tional programming language like Pascal, Algol, or PORTRAIT. 



ithead: 

if (pi ) then begin 
si ; 

goto <label>; 
end 

if (p2) then begin 

s2 ; 

goto <label>; 
end 



where <label> is ithead (a repeat) ! 

or ittail (a break) 



if (pn) then begin 
sn; 

goto <label>; 
end 

error ("it-ti fall through"); 
ittail: 

{rest of program! 



* The notation in this report differs from Farnas in: (1) no 
elseor - the predicates are assumed to be executed 
deterministically and sequentially; (2) no up and down arrows 
- the keywords repeat and break are used instead. 
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The array search problem sight be implemented using she it- 
ti as follows . 



index := 1 ; 
it 

index > sizeof(A) -> 'I(K); break; 

A[ index] = K -> ?(index); break; 

true -> index := index - 1 ; repeat; 



This seems to solve most, if not all, of the problems we have 
mentioned: there is no redundant boolean variable like 'found'; 

the search stops when the element is located; there are no redun- 
dant tests; there are no labels that redefine the 'shape' of the 
structure; the targets of the gotos implied by the repeats and 
breaks are visible and fixed; and any compiler worth its salt can 
factor out the constant boolean expression at code-generation 
time. Here we have a tight, efficient sequence of code. 

The traditional control structures are available using the 

a. j \J -L • 



if-then-else : 




if (b) then 


! it 
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for-loop: 




for i := 1 to n do 
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b -> bodyl ; break; 
true -> body2; break; 



= 1 ; 

i <= n -> (body) ; 

i := i + 1 ; 
repeat ; 

true -> break; 



while-loon : 



while (b) do 
(body) 
end; 



it 



ti 



b -> (body' 1 ; repeat; 
true -> break; 




3a se x of 



it 



xl : bodyl ; 
x2: body2; 



x = xl -> bodyl ; break; 
x = x2 -> body2 ; break; 



xn: bodyn; 
eni; 



-> bodyn; break 



repeat -loop: 



repeat 



(body) 
until b; 



init or b -> (body); repeat; 
true -> break; 



ti 



3- Evaluation of the it-ti 

There are several valid criticisms of the it-ti . For example, in 
order to handle the "execute at least once" loops (e.g. repeat- 
until, and the FCRTRAN-66 DC-loop) a new feature must be added to 
the it-ti construct (see the repeat-loop implementation. above): 
associate with each it-ti an 'init' variable that is true only on 
the first iteration. And to prevent unnecessary evaluation of 
the boolean 'b ’ in this structure, we must also require condi- 
tional evaluation of boolean expressions (probably not an unrea- 
sonable requirement, but one forced on us by the structure of the 
it-ti , nevertheless). 

!Tote also that the it-ti does not provide for efficient 
implementation of the case-statement. Without further enhance- 
ment, the it-ti deprives us of access to jump-table or hash- table 
implementation of selection constructs. The straightforward if- 
then-elseif approach to selection is not appropriate for all con- 
texts. 

Furthermore, practically speaking, the it-ti is not one con- 
trol structure but a family of control structures. Unlike a con- 
ventional repeat or while in which we know the control flew 
entailed by the structure without knowing the details of the 
code, the introductory keyword of the it-ti does not give us any 
information about the control flow of the following code. It 
simply announces that a section of code has been reached which 
’will contain alterations to sequential control flow. The reader 
will have to examine the body of each it-ti to understand the 
nature of the control flow. This criticism can be made concrete 
by observing that the 'traditional' control structures have a 
topologically constant flow chart representation as shown in Fig- 
ures 1 - 5 • 



Figure 1 . 



Pi sure 2 . 





Figure 3* 
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Figure 4- 



Figure 5* 



Repeat-loop 





No matter what 'b', 'x', or 'body' may be, the characteristics of 
the traditional control structures can be captured with a single 
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% e lone is to indicate a pseudo— decision node at 
guard clause: 




Figure 5. it-ti 




--.ere is no 
;he test that can 
the end of each 



They are not true decision nodes because there is no run-time 
decision to repeat or break: the programmer makes that decision 
tils i6sign Time . 

Since an it-ti with N guard clauses has 2**11 possible flow- 
graphs, a large it-ti , can be quite complex and obscure, and fail 
to satisfy the need for readable, maintainable code. One would 
hope that this additional complexity would be justified by an 
improvement in our ability to express algorithms, especially 
'simple' ones. But, there is still a simple control flow graph 
(from Xnuth [ 3 ]) that the it-ti cannot handle without contortion. 
Dijkstra called it the loop that is executed "n and a half times" 
( see Figure 7 ) . 




Figure 7- Dijkstra 's n-and-a-half-times loop 

If S is empty we have a while loop, and if T is empty vie have a 
repeat loop. In spite of the fact that the it-ti allows us to 



hand-craft a control structure to meet our needs, the "n and a 
half times loop" does not have a simple implementation using it. 
About the best we can do is to duplicate S, or introduce a 
boolean variable. 

S; 

it 

b -> 1: 3; repeat; 
true -> break; 

«v.L 



toggle := true; 
it 

toggle -> S; toggle := false; repeat; 
b -> 3; toggle := true; repeat; 

true -> break; 
ti 

This relatively simple control-flow graph can be implemented with 
an it-ti if we make a further extension to the construct . If we 
allow continue (fall through to the next guarded statement) as an 
alternative to break or repeat then 

it 

true -> S; continue; 
b -> T; repeat; 
true -> break; 
ti 

would do precisely what we wanted. However, continue , like the 
init variable introduced earlier, is not clean and is very ad hoc 
in nature. It increases the complexity of the construct 'chere 
are now 3**N possible flow graphs) and does not 'enhance the visi- 
bility of the code. 

And now, in order to implement intuitively simple programs, 
we find ourselves going through the same contortions with the 
it-ti that we have gone through with traditional programming 
structures . 



_Q_ 



Before we reject the it-ti entirely, however, let us look at one 
context in which the it-ti has proven effective. 

Veteran 113? programmers nay have a feeling of ieja-vu with 
the it-ti . In very many ways, it resembles the cond conditional 
of 113? except that the cond does not iterate. For non-veteran 
IIS? programmers, a short discussion of the control-flow struc- 
tures of LISP follows. 

4 • 1 ^ISP functions 

In most programming languages, a function is called with syntax 
that looks something like 

funcname ( parml , parm2 , . . . ) 

A LISP function application looks like: 

( funcname parml parm2 . . . ) 



4.2 cond 



The syntax of LISP'S control structure for conditional execution, 
the cond, is as follows. 

fcond (pi si ) 

(p2 s2) 



(pn sn) 

) 



The pi are predicate expressions evaluating to the LISP 
equivalents of true or false. The pi are executed sequentially 
’until one of them, say pj, evaluates to true . At that point, the 
list of statements sj is evaluated. When all of the statements 
in statement list sj are evaluated, interpretation commences at 
the first program statement after the final parenthesis of the 
cond. 



4-3 prog 

McCarthy [7] reports that he originally intended that LISP would 
be a FORTRAN-Iike list processing language 'with the addition of 
recursion and conditional evaluation of boolean expressions. He 
also admits that prog looks like an "afterthought", and that its 
iesign ’was an "afterthought". But it is this control structure 
that provides iteration via labels and go. If we assume that 
(An) is a function that returns the nth element of the array A, 
then the array search problem could be '.written in LISP as fol- 
lows . 
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'prog 'index' 

(seta index 1 . 

loop ;this is just a label, not a LISP keyword 

(cond ((greaterp index (sizeof A)) (go notfound)) 
((eaual (A index) K) (go found)) 

) 

(setq index (addl index)) 

(go loop) 
notfound 

(:t x) 

(return) 

found 

(? index) 

(return) 

) 



A more efficient LISP program to perform this search would be: 

(prog (index) 

(setq index 1 ) 
loop 

(cond ((greaterp index (sizeof A)) (II X) return) 

((eaual (A index; K) (? index) return) 

) 

(setq index (addl index)) 

(go Icon) 

) 

One can see that this transliteration from our pidgin-code into 
LISP results in FORTRAlI-like code which, when one thinks about 
it, is a far cry from the programming style indicated by the rest 
of the LIS? language: this goto style of programming is an abdi- 
cation of the applicative nature of LISP. 



5 • An alternative to prog 

A moment's thought will convince you that it is easy enough to 
incorporate the it-ti construct into LISP. The syntax of the 
cond is modified to accept one of the keywords break or repeat at 
the end of the statement list. The keyword break specifies that 
control exits the cond . The keyword repeat specifies that the 
cond is to be repeated. I.e., 

(cond (pi si [repeat/break 1 ) 

(p2 s2 [repeat/break]) 

(pn sn [repeat /break]) 

There are some differences between the enhanced cond in Ilavlisp 
and Parnas ' strict definition of the it-ti . for upward 
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crmpatib;. ty vit • current implementations :f II-'?. tr.o 

repeat /break is optional since one conventional cona is lefir.ei 
as if break were at the end of each statement list. And for the 
sane reason, the cond does not abort if all of the 

.guards/predicates are false. Unfortunately, this results in the 
loss of one of the distinct advantages of the it-ti : providing an 
effective ran tine check that each case has been anticipated. 

7ith this enhancement to cond , the coding of our example is 
concise: 

( seta index 1 ) 

( cond 

((greaterp index (sizeof A)) (N M) break) 

((equal (A index) K) (? index) ^ break) 

(T (setq index (addl index)) repeat) 

) 

Mote again that the keyword break is not necessary since that is 
the default action of the LIS? cond. 



5-1 examples 

Winston [5], page 32S, defines a non-recursive factorial function 
which is reproduced below: 

(defun factorial (n) ; written in Maclisp 

'prog (result counter) 

(setq result 1 ) 

(setq counter n) 

loop ; note the label 

(cond ((zerop counter) (return result))) 

(setq result (times counter result)) 

(setq counter (subl counter)) 

(go loop))) 

The following shows the result of defining the function using the 
modified cond. 



(defun factorial (n) ; ’written in Navlisp 

(let ((result 1) (counter n)) 

(cond ((zerop counter) result break 1 ) 

(T (setq result (times counter result)) 

(setq counter (subl counter)) 
repeat) ) ) ) 

The let used in the above example is a LISP function which, like 
the begin of Algol and the curly brace of C, defines an 
environment with local variables. That is, let is simply a prog 
without the complications of labels, go. and return . In Maclisp, 
let , prog , and an unmodified cond are available. In ITavlisp, 
only the let and the enhanced cona are necessary. 
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program to compute the 
function uses prog; 
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length of a . 



:he use of prog with a 
sc. His version of this 



(defun length (list) 

(prog (u v) 

(setq v 0) 

(setq u list 1 * 

a (oond ((null u'' ''return v' 1 ' 1 } 
(setq u (cdr u1) 

(setq v (addl v)) 

(go a) )) 



The following is a version using the modified cond . 

(defun lensth (list) 

(let (Tv 0) (u list) ) 

(cond ((null u) v break) 

(2 (setq u (cdr u) ) 

(setq v (aadl v)) 
repeat ) ) ) ) 

A more intricate example comes from Winston [5], page 334. If we 
assume that (matrix i j) is a function that returns the (i,j) 
element from a two-dimensional array named matrix , then Winton's 
version using prog is: 

(defun print-matrix (n m) ; written in Maclisp 

(prog (i j) 

(setq i 0) 
row-loop 

(cond ((equal i n) (return nil))) 

(terpri) ; prints an end-of-line 

(setq j 0) 

column-loop 

(cond ((equal j m) (go next-row))) 

(princ (matrix i j)) 

(princ '! !) ; prints a blank 

(setq j (addl j)) 

(go column-loop) 
next-row 

(setq i (addl i)) 

(go row-loop))) 

This program prints out the elements of a two-dimensional array a 
row at a time. The following is the Havlisp equivalent using the 
it-ti form of cond: 
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lefun prin~-matrix n a : written in Navlisp 
let (<i 0) (j); ; 2 is not initialised 

(cond ((equal i n) nil break) 

(1 (terpri) 

(setq j 0) 

(cond f (equal j a) break) 

(1 (printf (matrix i j) " '' j 
(setq ^ ''addi i)) 
repeat) ) 

(setq i (addl i)) 
repeat ) ) ) ) 

Our final example is the LISP interpreter function evcon coded in 
Navlisp . 



(defun evcon (beg a) 

(let ((c beg)) 

(cond ((null c) break) 

((eval (caar c) a) 

(let ((slist (cdar c)) (s (car (cdar c)))) 

(cond '(null s) (set 'c (cdr c)) break) 

( (atom s) 

(cond ((equal s 'repeat) (set 'c beg) 
break) 

((equal s 'break ) (set 'c nil) 
break) 



) 



(T 

)) 



(T 



(T (eval s a) 

(set 'c (cdr c)) 
break) ) 

break) 

(eval s a) 

(set 'slist (cdr slist)) 

(set 's (cond ((not (null slist)) 

(car slist)))) 



repeat ) ) ) 



repeat ) 

(set 'c (cdr c)) repeat) 



6. Conclusions 

Computer Science as a field is always on the lookout for program- 
ming concepts that simplify the art of programming. Parnas' it- 
ti is an interesting proposal to that end, but does have several 
serious drawbacks. However, the it-ti has proved itself a very 
apt programming structure for LISP, allowing the complex prog to 
be replaced by an enhancement to cond . The new cond is slightly 
more complicated than the old, but allows the writing of itera- 
tive programs whose structures are more within the programming 
spirit of LISP. This structure has been implemented in Navlisp 
and has proved itself to be both compact* and sufficient. 
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Appendix 



In [2], Dijkstra develops a programming language conducive to 
correctness proofs in which he defines two constructs he calls 
if-fi and do-od . He introduces the concept of the 'weakest 
precondition ' , written wp(S,R) and paraphrased as ' Ihe necessary 
conditions which guarantee that execution of statement 3 will 
leave the computation in state R. ' Parnas [l] cites Dijkstra ‘2] 
as his inspiration for the rt-ti, noting that "it is a "modifica- 
tion of the do-od and the if-fi . He does not, however, attempt 
to apply Dijkstra's 'weakest precondition' to the it-ti. Sor 
completeness, it is included here. Ihe reader is referrid to [2] 
for a complete discussion of the development of the weakest 
precondition for the do-od and if-fi . It should also be noted 
that the following discussion assumes non-determinacy, as do 
Dijkstra and Parnas. 

Let II refer to the it-ti: 



31 -> SI 

32 -> 32 



ti 



3n -> 



2n 



where the last statement in each Si is either break or repeat. 
At least one of the Bi will evaluate to true (.otherwise the 
results are ’undefined and ’will abort execution of the program) . 
That is, using the notation in [2]* **: 

(Si : 1 <= i <= n : 3i) 

Since the construct is non-deterministic, we can re-arrange the 
statements such that: 

(Bn : (0 <= m <= n) : 

( Ai : r ( 1 <= i <= m) and (Si ends with 'repeat')] 
or [(m <= i <= n) and (Si ends with 'break') ] )) 

If m = 0 then the construct corresponds to Dijkstra 's if-fi , and 
if m = n the construct is an infinite loop. This is effectively 
equivalent to che following: 



* It may interest some to know that it required only six 
additional lines of C-code to the Havlisp interpreter to 
implement the enhanced cond. 

** The notation uses Si to mean 'there exists an i ' , and Ai to 
mean ' for all i ' . 
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21 -> 21 
22 32 

2m -> 3m 
3d 
if 

2(m+1 ) -> 3(m+1 

2n -> 3n 
true -> error 



The last; statement of the if is necessary if m = n.) note that 
this assumes that for any iteration either 

(Ai : Bi : (Aj : Bj : f i in (1 ,m) and j in (1,m)] 

or [i in (m+1 ,n) and j in (m+1,n)] )) 

or that do -od / repeat statements take precedence over if -fi / break 
statements if more than one Bi is true. With these qualifica- 
tions on the it-ti we can arrive at its weakest precondition. 
Let DO' represent that sub-part of the it-ti that repeats , and 
IP' represent that sub-part of the it-ti that breaks, then 

wp(IT,R) = wp(D0' , wp(;?\R) ) 

where (from [2]) 

wp(I?' .R) - (Ej : m < j <= n : Bj) and 

(Aj : m < j <= n : Bj => wp(Sj,R)) 

wp(D0',R) = (Sk : k >= 0 : Hk(R) ) 

Hk(R) = wp ( IP , H(k-1 ) (R) ) or H(k-1)(R) 

HO(R) = R and not (Ej : 1 <= j <= m : Bj) 
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